chore(compose): run RustFS as the object storage of the stacks (#171) - #172

Proposed changes

• docker-compose.yml: the minio service runs rustfs/rustfs:1.0.4 instead of pgsty/silo:latest. Credentials come from the same .env variables (RUSTFS_ACCESS_KEY: ${MINIO_ROOT_USER}, RUSTFS_SECRET_KEY: ${MINIO_ROOT_PASSWORD}). The server /data command is gone. The healthcheck uses the RustFS readiness route /health/ready with curl, since the image has no mc, with a 60 s start period. Logs go to stdout (RUSTFS_OBS_LOG_DIRECTORY empty). RUSTFS_CHECK_UPDATE=false turns off the update check RustFS runs at startup (a call to version.rustfs.com, also attempted on air-gapped installs).
• docker-compose.dev.yml: same change on openaev-dev-minio, console kept on 9001, and a named volume rustfsdata (the anonymous /data volume of a previous Silo container belongs to root, RustFS restarts in a loop on it).
• README.md: "Object storage" section with the upgrade warning, the dev stack note and the link to the OpenAEV breaking changes page. .env.sample: comment updated.

Unchanged on purpose: service name minio, volume s3data, MINIO_ROOT_* variables, port 9000, MINIO_* variables of the OpenAEV service (the OPENAEV_S3_* names only exist from the OpenAEV release of OpenAEV-Platform/openaev#8839, and the stack runs latest images), collectors and XTM One S3_* settings.

The image tag is pinned to 1.0.4 (no latest): moving data to RustFS is one way, upgrades go through Renovate. No automatic migration: on an existing s3data volume, RustFS stops at startup with Permission denied until the volume is backed up and given to uid 10001, as described in the guide.

Related issues

• Closes chore(compose): run RustFS as the object storage of the stacks #171
• Do not merge before the OpenAEV release that contains feat(storage): run RustFS in dev and CI, rename the minio configuration to openaev.s3 (#8838) openaev#8839 is published and the guide is live on docs.openaev.io/latest: this stack runs latest images, and git pull users get the change at once.
• After merge: XTM-One-Platform/e2e-tests#31 follows (its dependency alignment check flags the storage until then).
• chore(compose): run RustFS as the object storage of the stacks (#620) OpenCTI-Platform/docker#621 (same change on the OpenCTI stack)

How to test this PR

Fresh stack:

cp .env.sample .env
docker compose up -d --wait minio
docker compose ps minio            # healthy
docker compose logs minio          # JSON logs

Then start the full stack, upload a document in OpenAEV and attach a file in XTM One.

Upgrade from Silo: follow the guide of OpenAEV-Platform/openaev#8839 (docs/docs/deployment/breaking-changes/MigrationVersion-s3-object-storage-rustfs.md, option 2). Without it, minio stops with Permission denied on the existing volume and OpenAEV waits for it: nothing is written.

Checked locally: docker compose config on both files; the service definition starts healthy on an empty volume, bucket creation, write and read work, logs come out on stdout (same check as OpenCTI-Platform/docker#621).

Checklist

• The PR title follows the Conventional Commits convention type(scope?): description (#issue)
• I signed my commits
• This PR is linked to an issue
• I consider the submitted work as finished
• I tested the code for its functionality
• I added/updated the relevant documentation
• Where necessary, I refactored code to improve the overall quality

Further comments

The repository has no CI on the compose files: the checks above are manual.

Unrelated, seen on the way: the README still shows a docker-compose.caldera-executor.yml command, a file removed from the repository; not changed here.